Implement P2300 get_scheduler bridge for executors#7238
Implement P2300 get_scheduler bridge for executors#7238shivansh023023 wants to merge 3 commits intoTheHPXProject:masterfrom
Conversation
Up to standards ✅🟢 Issues
|
|
Can one of the admins verify this patch? |
…local runtime init
75fba86 to
d384fd9
Compare
|
@shivansh023023 This is really a very interesting PR connecting our executor infrastructure to senders&receivers. Thanks for this. |
hkaiser
left a comment
There was a problem hiding this comment.
Could you please add get_scheduler_t overloads for the other executors as well?
| template <typename Exec, | ||
| typename = std::enable_if_t< | ||
| !std::is_same_v<std::decay_t<Exec>, executor_scheduler>>> | ||
| explicit executor_scheduler(Exec&& exec) |
There was a problem hiding this comment.
Could you please use requires() instead of SFINAE:
| template <typename Exec, | |
| typename = std::enable_if_t< | |
| !std::is_same_v<std::decay_t<Exec>, executor_scheduler>>> | |
| explicit executor_scheduler(Exec&& exec) | |
| template <typename Exec> | |
| requires(!std::is_same_v<std::decay_t<Exec>, executor_scheduler>) | |
| explicit executor_scheduler(Exec&& exec) |
|
Thanks for the review, @hkaiser ! I've gone ahead and addressed your suggestions: Modernization: Refactored the executor_scheduler constructor to use a C++20 requires clause, replacing the previous SFINAE/enable_if_t pattern. Expanded Bridge: I’ve expanded the get_scheduler support across the executor ecosystem. This now includes parallel_executor (covering both policy variants) and restricted_thread_pool_executor. Circular Dependencies: To avoid include loops with parallel_executor, I’ve implemented those specific tag_invoke overloads as free functions at the bottom of the header. Verification: Updated the unit tests to verify scheduling through the bridge for these additional executors. Locally, executor_scheduler_test is passing cleanly. |
|
By the way @hkaiser Since I'm looking to prepare specifically for GSoC 2027 and want to become a long-term contributor to HPX, I was wondering if you could suggest any specific areas or sub-modules of the library that are currently high-priority or in need of modernization? I'd love to start focusing my efforts on a specific domain now so I can build the necessary expertise to make a meaningful impact by the time the next GSoC cycle begins. Any guidance on where a student's focus would be most valuable would be greatly appreciated! |
PR Description: Implement P2300
get_schedulerBridge for HPX ExecutorsFixes
This PR addresses the ongoing effort to align HPX Executors with the C++23 P2300 (std::execution) proposal.
Proposed Changes
executor_scheduleradapter: Implemented a new bridge headerlibs/core/executors/include/hpx/executors/executor_scheduler.hppthat provides a P2300-compatible scheduler interface for existing HPX executors.get_schedulerforsequenced_executor: Added atag_invokeoverload forhpx::execution::experimental::get_schedulerinsequenced_executor.hpp, allowing it to be used directly in sender/receiver pipelines.executor_scheduler_senderandexecutor_scheduler_operation_stateto manage task dispatching via the executor.libs/core/executors/tests/unit/executor_scheduler.cppto verify the end-to-end flow:schedule(get_scheduler(exec)) | then(...).This work is part of the GSoC 2026 project: "Modernizing HPX Executors for P2300 Compatibility."
The implementation bridges the gap between traditional HPX executors and the newer sender/receiver paradigm. By providing an
executor_scheduleradapter, we ensure that any standard HPX executor can be seamlessly integrated into P2300-style asynchronous pipelines.Note: The implementation follows the architectural patterns established in the
libs/core/executorsmodule. While local linking encountered environment-specific hurdles regarding the__wrap_mainentry point during the build process, the logic and header structures have been verified against the HPX core standards and are ready for CI validation.Checklist